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DESCRIPTION 

Method and System for Efficient Access to Remote I/O Functions 

in Embedded Control Environments 

Field of the Invention 

The present invention relates, in general, to accessing I/O 
functions. More specifically, the invention relates to. 
accessing I/O functions that are remotely attached to a 
microcontroller. Still more specifically, the present 
invention deals with accessing such remotely attached I/O 
functions in embedded control environments . 

Background of the Invention \ 

In distributed embedded control environments I/O engines are 
often remotely attached to the embedded controller through a 
serial link. Typically access to these devices is facilitated 
by directly programming the serial link controller hardware. 

Fig. 1 shows such an environment where an embedded controller 
needs to operate a series of I/O devices which are attached at 
the remote end of a link. 

At the lowest level a microprocessor accesses I/O resources 
either through its I/O address space for architectures such as 
the Intel x86, or through its memory address space for 
architectures such as the IBM PowerPC. The software entity 
that controls the hardware at this level is usually called a 
Device Driver. Towards higher level software applications the 
Device Driver provides a generic view of the device. In UNIX 
systems, it is typically visible in the hierarchical file- 
system name space in the /dev tree and access to it is 
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facilitated using regular file-system semantics and interfaces 
like: 

open ( ) / 
close () ; 
read() ; 
write () ; 
ioctK) 

In embedded control applications it is not always possible to 
attach all I/O devices such that they can be directly 
addressed at the microprocessor bus level as shown in Fig* 2. 
The I/O functions are often implemented in a standalone ASIC 
which can be attached to the embedded controller' s 
microprocessor via some link hardware. Consequently, the 
resources of the I/O devices are not directly visible in the 
I/O address space or memory address space of the 
microprocessor. What is visible to the microprocessor though 
are the resources of the link hardware that connects the I/O 
ASIC with the embedded controller. 

Since no existing device driver can be used in this situation 
the full software path to the I/O devices needs to be 
facilitated through custom device interface software. The need 
for this custom device interface software is a limiting factor 
for time-to-market which is often key in the embedded control 
market nowadays. 

In addition custom implementation of the device driver layer 
increases the probability of shipping software bugs to the 
field which cannot be easily recovered fronu Unlike regular PC 
applications where it is relatively simple to download a new 
version of a previously buggy application over the Internet/ 
it is not easily possible to replace faulty software in 
embedded control applications* 
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Until recently this problem did not exist because embedded 
control applications traditionally used custom operating 
systems, custom device drivers, and custom hardware. Since the 
problem is rather new, standard solutions are not yet 
available, however, with the emerging push towards 
standardization in embedded control environments new solutions 
will become more prevalent. 

A major driver towards this standardization is Linux and the 
overall OpenSource movement. 

Summary of the Invention 

It is therefore an object of the present invention to provide 
a method for accessing I/O devices in embedded control 
environments thereby greatly reducing the programming effort. 

This and other objects and advantages will be achieved by the 
method disclosed in claim 1. 

Advantageous embodiments are laid down in the dependent 
claims. 

Brief Description of the Drawings 

The invention will in the following be described in more 
detail in conjunction with the drawings, in which 

Fig. 1 schematically shows an I/O card remotely attached to 
a microprocessor according to the state of the art; 



Fig 0 2 schematically depicts a microprocessor bus attached 
I/O; 
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Fig. 3 schematically shows a hardware solution according to 
the invention; 

Fig, 4 schematically depicts a software structure with a 
Device Abstraction Layer (DAL) according to the 
present invention; and 

Fig. 5 schematically depicts a sequence of events 

describing the DAL operation according to the 
invention. 

Detailed Description of the Preferred Embodiment 

The present invention allows for reuse of existing device 
drivers which are available for common I/O devices as long as 
they are mapped to the processor's I/O- or memory- address 
space in well known locations and with a well known layout. 
Reusing existing device driver code greatly improves the time- 
to-market capability and it reduces the software test effort 
as well. 

It has to be mentioned that the present invention does not 
change the existing device drivers but adapts them to a 
fictitious device. 

For remote but well known device types such as serial ports 
which are often referred to as UARTs (Universal Asynchronous 
Receiver/Transmitter) where device drivers exist for nearly 
all operating systems and Real Time Control Programs (RTOS), a 
Device Abstraction Layer (in the following called „DAL XX ) is 
provided which maps the devices * resources into the. 
microprocessor I/O address space or memory address space as if 
the remote device was locally available to the microprocessor. 
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Table 1 shows an example of UART resources as they are visible 
to the microprocessor as registers either in the I/O address 
space or the memory address space. By doing so, it is possible 
to instantly reuse existing device drivers and all the 
existing application software that uses them without the need 
to rewrite a vast amount of complex code. 



Table 1 UART Registers 



Offset 


R/W 


Description 


0 


R 


Receive Buffer 




W 


Transmitter Holding Register 


1 


R/W 


Interrupt Enable Register 


2 


R 


Interrupt Identification Register 


3 


R/W 


Line Control Register 


4 


R/W 


Modem Control Register 


5 


R 


Line Status Register 


6 


R 


Modem Status Register 


7 




Unused 


8 


R/W 


Divisor Latch (LSB) 


9 


R/W 


Divisor Latch (MSB) 



The implementation of the DAL is done 'in either one of the 
following ways: 

1. Embedding control hardware to redirect the requests and 
responses over the link to the remote device and still 
maintain the device abstraction. 

2. Using the microprocessor's memory management unit to 
cause a program exception as soon as the DAL' s resources 
are accessed which is done by providing a thin layer 
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device abstraction which executes in the context of the 
exception handler. 

As to the hardware solution, figure 3 shows how a 
microcontroller 2 or equivalent processor core within an ASIC 
device accesses the link logic 6 by a system bus 4 via a local 
register set 8 combined with a state machine. The link logic 6 
may communicate with a respective link logic 10 of the remote 
device, e.g., by using an appropriate and suitable protocol 
via link 16. The link logic 10 connects to a remote register 
set 12 containing a second state machine and attaches to the 
remote device 14 via a bus 18. It has to be mentioned that the 
link logic 6 can be any kind .of a data exchange (data link) 
between two stations A and B. This may be achieved by a simple 
serial interface, a LAN, a private network or a global 
network, etc., but is not restricted thereto.. 

The microcontroller 2 triggers, e.g., a read or write 
operation to the remote device 14 by writing to the local 
register set 8. This in turn activates the state machine in 8 
and controls the transfer of data to the link logic 6. The 
link logic units 6 and 10 transfer the request posted in 8 to 
the register set 12 and subsequently activate the respective 
state machine to execute the requested operation in 14, i.e., 
to write or read any data to/from the ^remote device 14. 

After completion of the operation the state machine 12 
triggers a response to be sent back via the link 16 and stored 
in a register of unit 8. This action may also cause a 
notification to the micro controller, e.g., an interrupt. 
Units 2, 6 and 8 may be designed as one single ASIC device 
integrating all functions or by use of standard vendor 
components that are interconnected as discrete modules . 
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The same approach is valid for the units 10, 12 and 14. While 
the link hardware 6, 10, 12 and 16 is required to overcome the 
physical distance between units 2 and 14, unit 8 may translate 
partially or fully to a software layer below the DAL. This 
allows for cost tradeoffs between hardware and software. 

Solution 1 mentioned above is used for rather simple I/O 
controllers where the hardware design effort is affordable and 
where performance requirements dictate it. 

Solution 2 is a software solution and is used where the 
hardware cost cannot be afforded but one can live with the 
overhead of entering and leaving the exception handler 
context. This solution will be described in more detail in the 
following. 

Fig. 4 schematically depicts a software structure with a 
Device Abstraction Layer (DAL) according to the present 
invention. 

The general mechanism used by the DAL implementation is a 
means for generating an exception during instruction execution 
upon accessing a virtual resource that does not physically 
exist. 

Two methods may be used to trigger the DAL, i.e., 

1) Use of the microprocessors *s management unites capability 
to generate an exception upon accessing a memory location 
where no real memory is mapped to; and 

2) Use of the microprocessor's execution unit's capability 
to generate an exception upon execution of a privileged 
instruction o 
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The following description of the DAL operation is based on 
method 1 but is also applicable to methods 2 and 3. 

The Device Abstraction Layer "DAL" facilitates the 
visualization of the remotely attached device and makes it 
appear to device driver software as if it was locally attached 
to the microprocessor bus. 

The following sequence of events as shown in Fig. 5 describes 
the operation of the DAL according to the described software 
solution and shows how it interacts with the rest of the 
system: 

During steady state operation, at some point in time the 
device driver for the virtual device may want to issue an I/O 
operation to the remote device. The device driver writes to 
the appropriate memory area in the microprocessor's memory 
address range (Step 1) . 

The Memory Management Unit of the microprocessor has been 
programmed such that read/write accesses to the relevant 
address range cause a Page-Fault Exception (Step 2) . 

Subsequently, the Page-Fault Exception Handler is invoked and 
a decision is made whether the exception needs to be handled 

i 

by the DAL or treated like a regular page-fault. 

The Exception Handler transfers control to the DAL (Step 3) . 
It provides sufficient information for the DAL to decode the 
operation that the device driver actually wanted to perform 
with the device. 

The DAL updates its internal state machine accordingly and 
issues the Start-I/O operations (Step 4) to the real device 
over the Link Driver as needed. 
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Once the I/O operation is complete at the remote device, an 
I/O complete interrupt is signalled to the microprocessor 
(Step 5) . 

Now, the interrupt handler decodes the interrupt source and 
passes control to the I/O complete handler in the Link Driver 
(Step 6) . 

The I/O complete handler decodes the event and passes DAL 
related events back to the DAL (Step 7) . 

The DAL retrieves the I/O information from the device via the 
Link Driver, updates its internal finite state machine tables 
and signals an I/O complete event to the device driver (Step 
8) . 

. \ 

The device driver issues read/write operations to the memory 
map of the device in order to obtain status of the I/O 
operation. Access to these memory locations again causes page- 
fault exceptions which are fed to the DAL which knows the 
relevant information from the I/O device already and thus can 
make it available to the device driver by completing the 
interrupted memory read/write operations. 
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CLAIMS 

1. Method for accessing I/O devices in embedded control 
environments, said I/O devices being remotely attached to 
an embedded microprocessor, 

characterized by the step of 

mapping said I/O devices x resources to said 
microprocessor^ address or memory address space. 

2. Method according to claim 1, characterized in that said 
I/O devices are selected from the group consisting of 
Universal Asynchronous Receiver/Transmitter (UART) , 
Universal Serial Bus (USB) , Joint Test Action Group 
(JTAG), and IC Bus (I 2 C) . 

3. Method according to claim 1 or 2, characterized in said 
mapping step is performed by a device abstraction layer 

(DAL) . 

4. Method according to claim 3, characterized in that said 
DAL is implemented via extra embedded control hardware. 

5. Method according to claim 3, characterized in that said 
DAL is implemented via software. 

6o Method according to claim 4, characterized in that said 
extra embedded control hardware redirects requests and 
responses over a link to the remote device. 

7o Method according to claim 5, characterized in that said 
DAL uses said microprocessor^ memory management unit to 
cause a program exception by an exception handler. 
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8. Method according to claim 7, characterized in that a thin 
layer device is provided which executes in the context of 
said exception handler. 

9. Method according to claim 7 or 8, characterized in that 
an exception is generated during instruction execution 
upon accessing a virtual resource unit. 

10. Method according to claim 9, characterized in that the 
microprocessor's management unit is used to generate an 
•exception upon execution of a privileged instruction. 

11. A computer system for accessing I/O devices in embedded 
control environments, said I/O devices being remotely 
attached to an embedded microprocessor, characterized in 
that said system comprises means for mapping said I/O 
devices * resources to said microprocessor's address or 
memory address space. 

12. Computer system according to claim 11, characterized in 
that said means is a device abstraction layer (DAL) . 

13. Computer system according to claim 12, characterized in 
that said DAL is implemented via extra embedded control 
hardware . 

14. Computer system according to claim 12, characterized in 
that said DAL is implemented via software. 

15. Computer system according to claim 14, characterized in 
that said software is adapted to cause a program 
exception as soon as the DAL's resources are accessed. 
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16. Computer system according to claim 15, characterized in 
that a thin layer device abstraction is provided adjusted 
to cause said program exception. 

17. A computer program product stored on a computer usable 
medium, comprising computer readable program means for 
causing a computer to perform a method according to any 
one of claims 1 to 10. 
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